Subject: Flow Control Replyt

From: Robin Layland <[email-masked]>
Date: Wed, 5 Jan 94 16:02 EST

Glade to see we are exiting ENTERBUSY. Here are my view on Shannon's messages,
Here are some fast comment to try to get the talk going before we get to LA.
 
Robin Layland 
ISSUES:
 
1)  Circuit Level Flow Control Mechanism.  Three popular candidates:
 
    a)  ENTERBUSY/EXITBUSY (XON/XOF)
    b)  FIXED PACING (window size negotiated at CAPEX)
    c)  ADAPTIVE PACING  (IBM we still need an answer on patents!)
 
    Open to proposals under the following rules:
 
    a)  Proposal must accomodate 6611-like implementations which simply
        don't send FC of any kind and only respond to ENTERBUSY/EXITBUSY
 
    b)  Any adaptive pacing proposal must not be proprietary and must be
        included as a negotiable option only.
  
          FIXED PACING is simply a special case of adaptive pacing in which
           the receiver maintains a constant window size and the sender
           sends the lesser of that fixed window size and his peer's
           last allowed window size.
 
    SUMMARY:  If we allow negotiation of initial pacing window size in
              CAPEX and:
 
                 a) zero means I don't support pacing (XON/XOFF only)
                 b) I don't support CAPEX implies zero
 
              then, those that wish to only support fixed pacing may
              negotiate their initial window size and leave it at that.
              Its even conceivable that hybrid connections could be
              negotiated such that pacing in one direction is fixed and
              pacing in the other direction is adaptive.
*****
*** I am for Fixed pacing with cap exchange turning it off. We don't have to
implement Enterbusy/exitbusy since the 6611 didn't implement this. If I am
wrong, then no fixed pacing on the cap exch would mean use Enterbusy/exitbusy (I
know developers don't want to do both.)  If fixed pacing is turned off, then the
reciever has the right to discard messages.

    
   RELATED ISSUES:
         a) Can IPMs be piggybacked on data?  This is tied to our decision
            below about the shape of the transport mechanism.
 
2) Transport Mechanism.  We must support this (6611):
 
       |--------------->|
   DLSw|  simplex TCP   |DLSw
       |<---------------|
 
   We might choose to allow these to be negotiated in the first release:
 
       |  duplex TCP    |
   DLSw|<-------------->|DLSw
       | data & control |
 
       |     data       |
       |<-------------->|
   DLSw|  duplex TCP    |DLSw
       |<-------------->|
       |     control    |

*The justification for having Data and control session is:
* - it allows use to implement priority and other features in the future easier.
There *can be one data session for priority one, another one for priority two. 
*- If we have only one session and for performance reason we need more, it is
easier *to do with separate session. Just increase the number of data sessions.
 
*There were some other reason given at the last meeting but I can't think of
them *right now. 
 
*As far as which is which, we can select one session number for control and a
second *number is always data.  Control is always started first and used for cap
exchange. If *we go this way I am not sure if we can piggyback pacing responses.

   If we're to undertake the latter two, then someone needs to sponsor a
   concrete proposal describing a justification and an algorithm to 
   unambiguously negotiate the mechanism.
 
   RELATED ISSUE:
      a)  Do we need a transport level flow control mechanism (slam it 
          shut)?  If so, we need to describe 6611 compatability here as 
          well.
* No, isn't that what TCP/IP flow control is for. If people don't like TCP/IP
then use a *different transport level protocol like APPN HPR as an option
(vendor option).
R